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ABSTRACT 

Current approaches to satellite observation data storage and distribution implement separate visualization and data 
access methodologies which often leads to the need in time consuming data ordering and coding for applications 
requiring both visual representation as well as data handling and modeling capabilities. We describe an approach we 
implemented for a data-encoded web map service based on storing numerical data within server map tiles and 
subsequent client side data manipulation and map color rendering. The approach relies on storing data using the lossless 
compression Portable Network Graphics (PNG) image data format which is natively supported by web-browsers 
allowing on-the-fly browser rendering and modification of the map tiles. The method is easy to implement using 
existing software libraries and has the advantage of easy client side map color modifications, as well as spatial sub- 
setting with physical parameter range filtering. This method is demonstrated for the ASTER-GDEM elevation model and 
selected MODIS data products and represents an alternative to the currently used storage and data access methods. One 
additional benefit includes providing multiple levels of averaging due to the need in generating map tiles at varying 
resolutions for various map magnification levels. We suggest that such merged data and mapping approach may be a 
viable alternative to existing static storage and data access methods for a wide array of combined simulation, data access 
and visualization purposes. 
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1. INTRODUCTION 

There are modeling applications relying on satellite data assimilations where both numerical values of the surface 
parameters as well as the visual representation of the datasets used are needed. An example of such combined modeling 
applications are space lidar simulations based on previously retrieved satellite data to estimate the performance of space 
based laser measurement instruments at varying locations around the globe, different seasons and times of day and night. 
We have been involved in the development of a modeling framework of this type with application to the Active Sensing 
of C0 2 Emissions over Nights Days and Seasons (ASCENDS) mission. The illustration of such lidar simulation is 
depicted in Fig. 1 showing physical parameters necessary to perform the required calculations. As can be seen, a 
simulation of this type relies on several datasets with satellite data assimilations to provide information about the 
atmospheric and surface parameters at locations of interest and over a specified time frame. The datasets with 
parameters of this kind include Modem Era Retrospective Analysis for Research and Applications (MERRA), CALIPSO 
aerosol data, MODIS surface reflection data, and ASTER digital elevation model. 1 " 4 All of the datasets listed above are 
normally accessed through FTP downloads and subsequent data extraction and manipulation on a client computer. Of 
these datasets, the surface reflection and ASTER surface elevation are 2D geospatial parameters which may be 
conveniently represented using a web-maps service. Unfortunately, such web-maps approach does not provide access to 



the numerical data values required for simulations and as such separate access to data and visualization is required 
resulting in software implementation complexity. 



(3) Surface elevation, (3» Surface reflection, (4) Vegetation index and 
(5) Other 2D surface parameters 


Fig. 1 Example space lidar simulation showing datasets used in analysis 

In this paper we suggest web-maps approach based on data encoding within map tiles with color rendering and data 
extraction on a client computer to allow combined data access, visualization and modeling capabilities. Software 
components and key functionality implemented based on JavaScript and other languages are described with advantages 
and limitations of the current data-encoded web-maps methodology summarized. Our suggested approach is applicable 
to any type of 2D data and is expected to be beneficial to the scientific community and many other fields. 


2. CURRENT DATA ACCESS AND VISUALIZATION METHODS 

Currently access to 2D numerical geo-spatial data and its visual representation are carried out using different 
approaches An example of such data access example is the NASA ECHO Reverb service where complete geospatial 
tiles for selected locations and datasets may be ordered and downloaded such as using the FTP protocol as illustrated in 
Fig la. 5 Such data ordering and downloading is time consuming and requires the usage of third-party data access 
libraries causing additional complications in simulation software requiring usage of geo-spatial data. On the other hand, 
a common approach used for the visual representation of such 2D geospatial information is in the form of web maps as 
illustrated in Fig lb for the Global Imagery Browser Services (GIBS). 6 Alternative visualization methodologies and 
systems exist such as Giovanni but those are not the subject of our proposed implementation. 7 The current web-maps 
approaches only provide visual representation of the data without the capability of accessing location specific numerical 
information. As such in applications requiring both visual representations of 2D geospatial data as well as access to the 
numerical values separate coding is required for data access and visualization. 

The complexity of current data access methodologies may be well illustrated using the ASTER-GDEM elevation 
model. 4 This dataset is not available for direct download due additional restrictions. There is a number of ways of 
obtaining the tiles from this dataset, one of which is through using the ECHO Reverb client. Unfortunately, if the entire 
dataset is required, ordering though the ECHO Reverb interface requires multiple iterations due to maximum order 


restrictions in addition to the necessary download agreement acknowledgements for each download. There are several 
stages in the ordering process including the tiles search, download agreement confirmation, ordering, and subsequent 
FTP download. Due to multiple restrictions and limitations on the maximum tile number per order in the ECHO Reverb 
service, when an entire dataset needs to be downloaded it is easier to write a script simplifying the ordering process 
introducing one more drawback in the development process. 


Reverb Data access example 


Global Imagery Browser Services (GIBS) 
web-maps visual representation example 




Fig 2 Examples of current approaches for separate data access and 2D data visualization 

Fortunately, many other datasets such as the MODIS surface reflection parameters may be downloaded directly 
using an FTP client such as from the LP DAAC website [3]. The data retrieval is a relatively simple process for the 
MODIS surface reflection data in this case. It should be noted however, that even if the data retrieval from a remote 
server is a relatively simple procedure, it is still necessary to handle the data access and visualization in separate ways 
which presents another complication. 

The 2D geospatial physical parameters used in a variety of applications are usually derived from various satellite 
and other datasets as shown for selected datasets in an example of Fig 3. As can be seen, the datasets which often come 
from different data provides have variable access requirements, often different data formats, file name conventions and 
data field names. As a result of these differences, modeling applications like the one presented in in Fig 1 example 
above in addition to time consuming process of data ordering and downloading to a local computer often require 
complex software compilation and integration of data access libraries necessary to access the datasets stored in different 
data formats such as HDF, HDF-EOS, GeoTIFF, netCDF etc. 
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Fig. 3 Format and file structure variations 


Additionally, due to the lack of data at lower averaging levels, the generation of visualization plots directly from the 
datasets downloaded this way makes real time visual data representation too computation complex. To address the 
above limitations as well as simplify and combine the modeling and visualization methodologies we have come up with 
an alternative data storage and access technique based on data-encoded web maps where numerical data is stored within 
map tile pixels for subsequent data rendering on a client machine using OpenLayers and custom JavaScript add-ons 
based on HTML5 functionality. 


3. DATA ENCODED WEB-MAPS IMPLEMENTATION 

The proposed approach of data-encoded web maps is based on storing of numerical values of 2D parameters within 
image pixels using PNG format with lossless compression resulting in lower file size. 8 The advantage of the PNG 
format is the direct support by web browsers allowing in-browser data extraction from the data-encoded image pixels. 

Fig 4 illustrates the available data storage formats for PNG files to store geospatial data. 


Table 1. Illustration of the available PNG data formats and the corresponding bits per pixel 


PNG image type 

Color type 

Maximum bits per pixel 

Truecolour with alpha: red, green, blue, alpha 

6 

64 

Greyscale with alpha: grey, alpha. 

4 

32 

Truecolour: red, green, blue. 

2 

48 

Greyscale: grey. 

0 

16 

Indexed-color: palette index 

3 

8 


As can be seen from Table 1, the maximum filed width for each pixel in a PNG image is 64 bits corresponding to 
the maximum data size typically used in file formats such as HDF. In most cases fewer bits per pixel are required to 
store data such as in the case of the ASTER global digital elevation model with 16 bit fields per pixel is the geoTIFF 
data files, and the HDF-EOS datasets most often using 32-bit encoded values. As such, the PNG format is sufficient to 
represent geospatial data for most common purposes by using different available color schemes requiring different pixel 
depth values. It should be noted, that the PNG files contain several data fields available for storage of additional 
information about the image which could be used for custom information pertaining to the data stored within data- 
encoded PNG tiles. Such approach would be very similar to the geoTIFF format where certain informational fields are 
used for such purposes. If is desirable that a generally accepted encoding standard is introduced to encode data 
requiring various number of bits into different PNG type image formats to represent 2D data. 
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Fig 4 Illustration of possible data and error merging within the same tiles for an ASTER-GDEM tile 

near mount Everest (tiles N27E086). 



Due to the maximum available pixel depth of 64 bits it is also possible to encode multiple datasets containing 
complimentary data within the same web-map tiles. For example, the ASTER global digital elevation model currently 
uses separate geoTIFF formatted files to store the data and the associated precision parameters. Each of these 
parameters are encoded with the color depth of 1 6 bit thus making it possible to merge them within the same set of data- 
encoded web map tiles for easy simultaneous access to both. For example, Fig 4 illustrates the possibility of merging the 
elevation data from the ASTER-GDEM dataset with the precision information using the data-encoded web maps. 

The data-encoded web maps approach requires generating map tiles with different resolutions slightly increasing the 
data storage requirements. However, due to the ever decreasing resolution for lower accuracy map scales, the increase in 
the required space is not very significant. To illustrate this, Table 2 summarizes the increase in the required data storage 
space compared to the highest resolution data set as the number of generated lower resolution maps is increased for the 
ASTER-GDEM geoTIFF file format currently in use. 


Table 2 Example data storage requirement reduction for the ASTER-GDEM geoTIFF map tiles 
as a function of different resolution levels achieved due to averaging. 


Spatial resolution, meters 

Approximate size, Mbytes 

30 

~ 1000000 

60 

250000 

120 

62500 

240 

15625 

480 

3906 

960 

976 

1920 

244 

3840 

61 

7680 

15 

15360 

4 

30720 

1 

Total size, Mbytes: 

-1335000 


As can be seen, even though there is a certain increase in the required disk space, such methodology presents a 
significant number of important advantages such as a set of averaged data with different averaging levels for different 
spatial resolution simulations. Additionally, custom color rendering on a target system may be achieved with data 
filtered by a range of given physical parameters. 

The implemented approach has much broader applications than space lidar simulations and is useful for a wide 
range of other location specific web-map data representations. The advantages and limitations of the data-encoded web- 
maps approach are as follows: 

Disadvantages of the current data ordering and handling: 

1) Need to order individual datasets (not all datasets have direct FTP access) 

2) Often complicated and time consuming data ordering and downloading for applications where access to the entire 
earth coverage data is needed. 

3) Variations in file and data field names in files requiring separate handling of each dataset 

4) All datasets often need to be located on the target system 

5) Separate software library to access to different dataset formats (complicated compilation and linking is necessary) 

6) Separate coding is necessary for special and temporal visualization of the data. Visualization data source is often 
different from the simulation data. 



7) Additional coding to implement data averaging may be required (lower resolution simulations). 

Advantages of data-encoded maps 

1) Combined and easy to implement data access and visualization method. Same access and data handling approach 

2) Same source of data for modeling and visualization 

3) Multiple levels of averaging 

4) User-defined client side color rendering scheme 

5) Spatial data sub-setting 

6) Capability of data filtering by a range of physical parameters 


4. DESCRIPTION OF SOFTWARE COMPONENTS FOR THE DATA-ENCODED 

WEB MAPS IMPLEMENTATION 


The data-encoded web maps approach relies on the HTML5 components, OpenLayers library, and one of the server 
side web-maps frameworks such as GeoServer. 9 " 11 Additionally, The implementation of the data-encoded web maps 
approach relies on 2 custom libraries under development: one to carry out data extraction and custom color rendering on 
the client computer using JavaScript language as an add-on component to the OpenLayers open source library and the 
second library to carry out conversion from the currently commonly used data formats such as HDF-EOS, NetCDF and 
geoTIFF into the data encoded web maps as shown in Fig 5. 


- Existing third party libraries 


- Additional custom components to be implemented for the data-encoded web-maps approach 


- Comments and data sources 
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Fig 5 Description of the software components under development for data-encoded web maps implementation 


This later set of software components relies on the cross-platform modules previously developed for the lidar and 
atmospheric transmission simulation framework which is based on several different third party libraries enabling 
different dataset encodings. 12 The JavaScript add-on to OpenLayers would provide several additional controls and 
capabilities currently unavailable in the OpenLayers library to perform several additional functions and provide 
additional interface components as illustrated in Fig. 6 

As can be seen these components serve several purposes such as 1) the selection of the map color rendering scheme, 
2) visual filtering of the data by providing a range of physical parameters of interest, and 3) extraction of the data based 
on the specific location coordinates from the web-map riles at different map resolutions thus providing data with 
different averaging levels. The components may be developed using a number of JavaScript libraries such as JQuiery 13 
The pixel data extraction is the direct capability of HTML5 components and is illustrated in the OpenLayers 
development version examples which use this feature and may be found online. It should be noted however that 
complete implementation of such strategy only makes sense if data-encoded web-maps are available which is not 
currently the case to the best of our knowledge and is the subject of this paper. 
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Fig 6. JavaScript additional add-on interface components and their functionality 


The purpose of the JavaScript add-on framework to OpenLayers is to both provide ready-made interface 
components for used-selected filtering and visual scheme modification as well as to enable easy integration of custom 
user-supplied code for data manipulation and custom color rendering scheme changes. By using such approach the data 
extraction from the map tiles may be carried out either manually at the current cursor position or programmatically by 
specifying the latitude and longitude of the point of interest. Both of these approaches would rely upon the standard 
OpenLayers components but also require lightweight additional JavaScript add-ons specifically targeting the data- 
encoded web maps approach. 


5. GENERAL ILLUSTRATION OF SELECTED FUNCTIONALITY 

An example shown below illustrates one of the data-encoded web map capabilities using the features described in 
the previous section applied to the ASTER surface elevation dataset. In particular, Fig. 7 shows data filtering of the 




surface elevation values by a range of given altitude parameters achieved using the range filtering control described 
earlier. 


Complete altitude coverage Filtered altitude coverage (0 - 2km) 



Fig 7. Visual sub-setting (physical filtering example) for ASTER-GDEM surface elevation model. 


Fig. 7a illustrates a standard color-encoded surface elevation plot, and 7b shows the same plot containing only the 
parts of the surface with elevation values in the range of 1 to 2 km. As mentioned above such functionality is achieved 
within the browser not requiring any additional coding. 
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Fig 8. Illustration of different data-encoded web maps averaging levels for the ASTER digital elevation model 
tile N27E086 corresponding to a location near Mount Everest. 


Fig 8 illustrates the different data averaging levels at a location near Mount Everest (ASTER-GDEM tile N27E086) 
achieved by subsequent combining of values in adjacent tile pixels. The tiles have been resized to have the same size 
and smoothed for better representation, with the actual number of pixels and grid resolution shown for each tile image. 
The effect of averaging is clearly seen. Since the data-encoded web-maps implementation automatically stores data at 
different averaging levels, switching between one map magnification to the other typically done by a mouse wheel 
results in access to different averaging levels of the same dataset. 



6. CONCLUSIONS 


A data-encoded web-maps approach has been suggested for the representation of 2D geospatial data. It is shown 
that the suggested methodology has numerous advantages compared to the currently implemented separate data access 
and visualization methods. The suggested approach is better suited for applications not requiring very complex data 
extensive modeling applications and has the advantage of fast and easy access to the required 2D data with added 
visualization capabilities. 

A JavaScript add-on to the OpenLayers and software for conversions to PNG tile under development are described. 
It is hoped that the software components developed for this project will be made available in an open source format once 
the development is complete. 
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